Managing Subscriptions through Email

In a perfect world, subscribers would understand intuitively how to subscribe and unsubscribe from mailing lists. Unfortunately, this is not always the case. Depending on an individual's style of list management, a list owner may choose to add or delete subscribers to the list manually, or send the potential subscriber instructions on how it is done. (See Appendix B: Sample Boilerplate Files for sample "boilerplate" instruction files that can be modified to suit local purposes.) And for lists coded Subscription= By_Owner or Subscription= Closed, it is of course necessary to use the ADD command to subscribe a user.

If the list is set to confirm mailing paths for new subscriptions (Subscription= Open,Confirm), it is probably wisest to use the latter option, since if a subscriber is added manually to a list, the confirmation process is bypassed.

Full_name should contain at least two discrete words, but it is also possible to add users without knowing the value for full_name. Simply use an asterisk ("*") character. If the user is already subscribed to another list on the same host, LISTSERV will pick up the value for full_name from its signup files. Examples are:

RIGHT: ADD DOAKES-L joe@example.com Joe Doakes

RIGHT: ADD DOAKES-L joe@example.com *

WRONG: ADD DOAKES-L joe@example.com Joe

WRONG: ADD DOAKES-L joe@example.com Joe-Doakes

When adding users, ADD will also accept a full RFC822 address that you can cut and paste from the "From:" line of a message. Be sure that you remove the "From:" part of the line. For example, the "From:" line

becomes an ADD command as follows:

Although this is not as much of a problem as it used to be, it can happen with any system which allows users to have a very long "local part" (i.e., the part to the left of the "@") in their userid, or with users on systems that just have very long names, such as some of the hosts in the .US domain generally have. For instance, you might try to send the following ADD to LISTSERV:

"His Name" wraps to the next line. If you send this to LISTSERV, LISTSERV treats the two lines as separate commands even though you did not hit RETURN after the user's address, and it responds:

> QUIET ADD MYLIST someone.with.a.real.long.userid.that.wraps@hishost.com someone.with.a.real.long.userid.that.wraps@HISHOST.COM is not yet in the signup file. Please specify the full name of that person, as in "ADD MYLIST JOE@XYZ.EDU Joe H. Smith".
> His Name
Unknown command - "HIS". Try HELP.

To avoid this problem, set up your ADD command with a "continuation card" as follows:

Typically this was a problem primarily with the X.400 and X.500 addressing schemes, which are not as prevalent as they used to be.

X.400 and X.500 addressing schemes can cause problems for the list owner who is trying to add or delete one. These addressing schemes use the "/" character to separate address elements, but to LISTSERV, "/" is a special character and you would not be able to add or delete one of these addresses by simply cutting and pasting it into an ADD or DELETE command.

For instance, you might have an address like:

In order to either add or delete this address, there are two issues:

For adds, to get around both of these issues, you must use a LISTSERV JOB syntax as follows:

Any other method will trigger an RFC822 parser error because of the "/" characters in the address. (A user who is subscribing from an address like this will have no trouble; it is only when the list owner uses the ADD command that this difficulty surfaces.)

For deletions, to get around both of these issues, the wildcard character ("*") can be used. You may not need the entire address in order to delete it, so you might just use

which solves both the line wrap problem and the illegal character problem at the same time.

You can also use double-quotes around the address if it contains illegal characters, and a "continuation card" (see Section 13.1.3 Continuation Card Syntax) if the address is too long to fit on one line:

The basic syntax of a continuation card is

or, for instance, for a large GETPOST job,

Without going into a lot of detail, the "//<space>" at the beginning of the command causes LISTSERV to look for a comma at the end of the first line and, if if finds the comma, to add anything following the comma on the second line to the end of the first line. Be sure to put a space before the comma at the end of the first line, as LISTSERV will not add the space for you.

For more information, see the section on LISTSERV's Command Jobs Language Interface (CJLI) in the Advanced Topics Manual for LISTSERV.

Sometimes the list owner will get a message from a subscriber who says, in essence, "I keep trying to (unsubscribe/change to digest/etc.) and LISTSERV says I'm not subscribed. Can you help?" This requires some detective work.

There are a couple of strategies for figuring out what is wrong. List owners should first use the powerful SCAN command to search for a pattern anywhere in the subscriber list. The syntax is:

For instance, "SCAN TEST-L Nathan" might return:

Searches with SCAN should start out simple and become more complex as needed. For instance, if there are only three people in the list with the string "NATHAN" as part of their subscription record, it will be unlikely that you will need to make the search any more complex. If you are looking for "SMITH", however, it may be necessary to further qualify your search string, say to look for "JOE SMITH". Another reason it is important to begin with a simple search string is that your user may not be subscribed under the exact address the error is returning to you. For instance, say you don't have the user's id, but you have a host name. You can search for all occurrences of the host name, but note that the search:

will not find the user jsmith@foo.bar.com. If you run the following search:

however, you will find Mr. Smith's subscription.

Another possibility is that the subscriber may be using more than one address to work with his subscription. For instance, say the user's complaint to you came from JOE@SUN6.SOMEUNI.EDU. Looking at the list, you find a subscription for JOE@SUN8.SOMEUNI.EDU. LISTSERV has no way to know that JOE@SUN6 is the same person as JOE@SUN8, even though Joe and you know they are. The solution to Joe's problem above is for you to delete his SUN8 subscription and add his SUN6 address. Then Joe needs to be sure that he uses SUN6 in the future, if not for reading mail, then at least for managing his own subscription.

Another strategy would be to submit a wildcard QUERY to the list. The drawback to this method is that it might require multiple tries to find the subscription, depending on the complexity of the wildcard query.

Note: Not only can this sort of problem arise from a subscriber using more than one workstation to read mail, but it can also arise when a particular site changes its domain configuration, forwards mail from the old addressing scheme to the new addressing scheme, and doesn't inform its users of the change. In these cases, users often don't realize there is a problem until they try to unsubscribe or change personal options, because the change has been transparent to them.

Currently there are no supported conversion programs that will take (for instance) a Majordomo or ListProc mailing list and convert it to LISTSERV format. However it should be possible to extract the address list from the non-LISTSERV list and use a bulk add operation (see Section 13.4 Adding Subscribers to Lists in Bulk) to populate your new LISTSERV list.

Existing list archive notebooks will probably not be in LISTSERV format (a modified VM MAILBOOK format), but rather, in the standard unix mailbox format. Again there are no supported programs to convert such archives to the LISTSERV format, but the basic format is as follows:

Message separator
Body of Message
Message separator
Body of Message

The MAILBOOK message separator is a line of 73 "=" characters (ASCII &H3D). Each archive notebook file must start with a message separator as the first line, e.g.:

=========================================================================
Date: Tue, 3 Mar 1998 10:36:55 -0500
Sender: Test list <TEST@LISTSERV.EXAMPLE.COM>
From: Nathan Brindle <nathan@example.com>
Subject: Test
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

First test message
=========================================================================
Date: Tue, 3 Mar 1998 10:39:11 -0500
Sender: Test list <TEST@LISTSERV.EXAMPLE.COM>
From: Nathan Brindle <nathan@example.com>
Subject: Test2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

and the notebooks must be named in a standard LISTSERV format, e.g., TEST.LOG9803A, so that LISTSERV will see them and include them in the output of the INDEX listname command.

Note: For unix mailbox-formatted archives, you must remove the first line of each message, which begins with "From" followed by a space (this is the standard unix mailbox delimiter). Below is an excerpt from a unix mailbox for illustration purposes:

From owner-test@listserv.example.com Mon Dec 29 15:17:20 1997
Return-Path: <root@listserv.example.com>
Received: from localhost (root@localhost) by listserv.example.com (8.8.3/8.8.3) 0
Date: Mon, 29 Dec 1997 15:17:20 -0500 (EST)
From: root <root@listserv.example.com>
To: test@listserv.example.com
Subject: Test
Message-ID: <Pine.LNX.3.95.971229151703.711A-100000@listserv.example.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status:

Root
From owner-test@listserv.example.com Mon Dec 29 15:23:51 1997
Return-Path: <root@listserv.example.com>
Received: from localhost (root@localhost) by listserv.example.com (8.8.3/8.8.3) 0
Date: Mon, 29 Dec 1997 15:23:51 -0500 (EST)
....

Each of the lines beginning with From owner-test@listserv.example.com is the delimiter separating one message from the next.

If you are moving a list from a non-LISTSERV site, you can quickly and easily convert the existing subscriber list to the LISTSERV format by following these instructions:

Create an add job as follows. The QUIET and IMPORT command words are optional; omit the square brackets if you use them. The "full name" field is optional as long as you use the IMPORT option; otherwise you must either specify "*" (for an anonymous subscription) or a full name consisting of at least two separate words.

If you are importing from an existing non-LISTSERV list, you should remove any lines from the original list that do not actually identify subscriber addresses. If you are converting to LISTSERV from ListProc, note that LISTSERV will not convert ListProc user options to their LISTSERV equivalents; you must take a line like

The IMPORT option implies a QUIET ADD (in other words, you do not need to specify QUIET if you use IMPORT) and otherwise vastly speeds up the ADD process by loosening syntax checking and omitting success messages. If you do not use the IMPORT option and do not specify QUIET, the users you bulk add will receive the normal SIGNUP message and/or WELCOME file as usual.

If you have a large number of users to delete at one time, you can use a bulk delete syntax that is similar to the bulk ADD documented above. However please note that there is no "IMPORT"-type option for this feature, and as usual for the DELETE command you specify only the user's address in the data DD.

There is, however, a BRIEF option that can be specified which is good when you don't want a long list of "userid@host has been deleted from list xxxx" messages, one for each user deleted. Use of the BRIEF option tells LISTSERV to return only a count of the users that were deleted.

Once again you construct a LISTSERV JOB framework as follows and then send it to LISTSERV:

[QUIET] DELete listname DD=ddname [BRIEF] PW=yourpassword
//ddname DD *
userid1@host1.com
userid2@host2.com
...
useridn@hostn.com
/*

You will probably want to use the QUIET modifier when doing a bulk delete, in order to suppress the notification message to the users being deleted.

Prepending the command word "QUIET" before any LISTSERV command that you issue on behalf of a subscriber causes LISTSERV to suppress any notification to the subscriber of the changes you have made. This is particularly helpful when deleting subscribers whose accounts have expired and when setting subscribers with full mailboxes to NOMAIL, as it will help avoid another error message from the host when the notification message bounces. It is also helpful when adding subscriptions to the list that should not receive any welcome mail, such as redistribution lists and USENET newsgroups.

Examples of the usage of QUIET include:

A bounce is simply an undeliverable e-mail message. The term "bounce" is used to describe it because normally the system that discovers the delivery error "bounces" a copy of the message back to you with some sort of delivery error message. Sometimes these messages are easy to decipher – "No such user at foo.bar.com" – but uncomfortably often they are not that easy. Certain systems, as noted above, kindly format error notifications in a format that LISTSERV can understand, and if your list is configured for auto-deletion, these bounces will be the least of your worries – in fact, they will not be worrisome at all.

If you receive bounces processed through LISTSERV you will note that they normally say something like the following at the top:

What this message means is simply that LISTSERV has received mail sent to the owner-listname mailbox for your list. Mail sent to this special address is automatically forwarded by LISTSERV to the address(es) you have defined in the Errors-To= list header keyword. The little "error-header" shown above is prepended to the actual error message to let you know that this is an error for your list (rather than unceremoniously dumping it into your mailbox and making you wonder "why did I get this?", since some delivery errors aren't specific about what list or even what user they are for). So whenever you get mail saying it was found in the owner-listname mailbox, it means that it is an error that you need to deal with for the list referred to by listname.

If you find that you have users trying to contact you (as list owner) at the owner-listname address, you should tell them that the correct generic address for contacting the list owner(s) is listname-request, not owner-listname. Mail sent to the listname-request address will be sent to all non-quiet list owners and furthermore will be automatically responded to with the REQACK1 mail template form from your listname.MAILTPL file (or its default from DEFAULT.MAILTPL; see Section 18 Working with Mail and Web Templates Using Email) while mail to owner-listname will not be responded to at all unless you do so explicitly. The nice thing about having people use the listname-request address is that you can store your list's FAQ (if you have one) in the REQACK1 mail template form and probably not have to answer all of the questions you get as list owner--like "how do I subscribe?" and "how do I sign off?".

Note: It is not the intent of (nor would it be reasonably possible for) this manual to document each and every kind of delivery error that you may ever see as a list owner. Unfortunately, and completely outside the control of anyone at L-Soft, new types of cryptic, difficult to understand, and totally misleading errors appear all the time. If you run across something not otherwise documented here, the best place to ask for help is the LSTOWN-L mailing list (see Section 19.6 If I can't find the answer, where do I turn?).

That being said, here are a few of the typical mail errors you will have to deal with as a list owner. Newer, so-called "Notary" format error codes are documented in RFC1893, which can be found at the WWW URL

http://www.ietf.org/rfc/rfc1893.txt?number=1893

Most of the time, this is authoritative and indicates that the user's access has been curtailed for some reason (graduation, no longer employed, etc.). A quiet delete (syntax: "QUIET DELETE listname userid@host") is in order unless you have reason to believe that the message is not authoritative. Variations on this message include "Recipient unknown" and "Ambiguous address: userid". The latter doesn't really mean the user doesn't exist, but it's almost as bad, and many list owners choose to classify it as "no such user".

This is sometimes authoritative and sometimes not. If a host goes down or a gateway fails, often this message is returned by an intermediate host or gateway. If the user is bouncing a great deal of mail from a high-volume list, it is probably best to set the user to NOMAIL (syntax: "SET listname NOMAIL FOR userid@host") rather than to summarily delete him. This way, the error messages stop, the user is sent an automatic message telling him his personal options have been changed by the list owner, and the user doesn't have to go through the subscription process again if the problem has been solved in the interim.

The problem is that some hosts go down on a regular basis and this error makes it impossible to tell if the host in question is gone forever or gone until the local sysadmin reboots his machine. After a while, you will begin to recognize the transient hosts and may elect to ignore them. If you choose to set the user to NOMAIL, you should send a message to the user just in case the system has come back up, and you should keep some sort of record of the users you've set this way so you can follow up later with another message.

Similar to "no such host". This means that the Domain Name Service (DNS) can't find any routing information for host but has found at least one reference to it. This generally indicates a DNS configuration error and may or may not be transient.

A host is experiencing periodic failures, and the gateway or intermediate host has not been able to deliver the message for n days. Usually the host will attempt redelivery. Usually there is nothing wrong with the user address, so it is a list owner decision as to whether it is worth waiting out the transient failure or going ahead and setting the user to NOMAIL. Unfortunately, by the time you get this message, the failure is n days in the past, the "transient failure" is very probably over, and you are likely to receive further error messages for n more days until the intermediate host's queue is exhausted.

This usually happens on systems with tiny user mailbox space, but it can happen on any system if a user subscribes to too many lists or goes on an extended vacation without setting lists to NOMAIL. The best solution is to set the user to NOMAIL yourself. Variations on this message include VMS's "file extend failed writing to [disk.user]MAIL.MAI".

This is a favorite Unix sendmail configuration bounce. NOMAIL or DELETE, according to your preference. Since it is a configuration problem, it is usually transient. One system sent the following under an "unknown mailer error 1" heading:

This is apparently a "mailbox full" error, as "userid's" mail spool is "over quota". It is also possible that it means your message would put the user over quota by 935 bytes. Either way, there isn't enough space in the user's mailbox to store your message (in this case, it was a daily digest). Note that "unknown mailer error x" does not always mean the user's mailbox is full – what it always means is that sendmail cannot identify the cause of the error.

While talking to smtp.ccabc.com:
>> DATA
<< 554 I/O error to mailbox
554 MILLERT@smtp.ccabc.com... Service unavailable
----- Recipients of this delivery -----
Bounced, cannot deliver:
MILLERT@smtp.ccabc.com
Sent successfully:
<MILLERT@ABC.COM>

What this means (assuming that the mail hasn't gone through a redistribution list or a mirror site) is that you have a user MILLERT@ABC.COM on your list, and the server accepted the mail for that address successfully. However, that address actually maps to a different internal address (in this case MILLERT@smtp.ccabc.com) and for whatever reason, the server can't forward the mail on. This is the equivalent of a "user unknown" error for MILLERT@ABC.COM.

Means that the message has transited through too many intermediate mail systems (1 transit = 1 hop). Most of the time this will be due to a temporary looping condition on the user's end (despite the "permanent" 5.4.6 error). For instance, the following Internet routing headers indicate a loop between three different mail machines (starting from the bottom and working back to the top):

Received: from un1.sample.com (root@un1.sample.com [200.9.212.3])
by un7.sample.com (8.8.7/8.8.7) with ESMTP id RAA22765
for <user@example.com.ar>; Wed, 4 Mar 1998 17:17:10 -0300
Received: from ul1.sample.com (root@ul1.sample.com [200.0.224.2])
by un1.sample.com (8.8.7/8.8.7) with ESMTP id RAA27352
for <user@example.com.ar>; Wed, 4 Mar 1998 17:16:00 -0300
Received: from un7.sample.com (un7.sample.com [200.9.212.4])
by ul1.sample.com (8.8.8/8.8.8) with ESMTP id RAA13496
for <user@example.com.ar>; Wed, 4 Mar 1998 17:15:40 -0300 (GMT-3)
Received: from un1.sample.com (root@un1.sample.com [200.9.212.3])
by un7.sample.com (8.8.7/8.8.7) with ESMTP id RAA22034
for <user@example.com.ar>; Wed, 4 Mar 1998 17:15:27 -0300
Received: from grape.EASE.LSOFT.COM (grape.ease.lsoft.com [206.241.12.34])
by un1.sample.com (8.8.7/8.8.7) with ESMTP id RAA25235
for <user@example.com.ar>; Wed, 4 Mar 1998 17:08:43 -0300

The problem here appears to be that the mailers at sample.com are MX (mail exchanger) sites for example.com.ar, but that they can't decide which one of them should hold onto the mail until it can be delivered to example.com.ar. So it looped through 7 iterations until the un7 machine finally decided that enough was enough (including the passage through LISTSERV it had taken 26 hops and un7 was set to accept a maximum of 25 hops) and generated an error.

You may occasionally see a "too many hops" message that isn't a loop. Usually the non-looping variant is due to the recipient being many hops away from the mail originator and the maximum hop count being set too low on the recipient's machine. Many older sendmail installations, for instance, will accept only 10-15 hops before they reject the message. With today's Internet a setting of 30-40 is probably much more reasonable.

A particularly annoying error you may have to deal with (unlikely these days as this kind of addressing is becoming quite obsolete) comes from Banyan networks and is of the form:

Obviously this is not a properly-configured address (at least, not as far as LISTSERV is concerned), and if you SCAN or QUERY the list for it, you will get a negative response. If, however, you SCAN the list for LLONG, you may find a user such as:

> scan test-l LLONG
Bill Smith <LLONG%StarShip%Dora@BOONDOCK.TERTIUS.COM>
SCAN: 1 match.

This user can now be set to NOMAIL and the errors will stop after the Banyan host has emptied its queue. If you do not find the user on the first SCAN, try using another part of the address as your search text.

Notes: A user may have his mail forwarded from the account that is actually subscribed to an account on another machine where he reads his mail. If the second machine is bouncing the mail, it may not be immediately apparent from the bounce messages that the mail is actually being forwarded. It is important to check for variants of the userid in the bounce message as it may be related to the userid that is actually subscribed to the list.

There are many forms of error messages. Many mail systems do not conform to Internet "standards" (some of them even return non-English error messages!) and LISTSERV's auto-deletion feature will not always catch their bounces.

Perhaps the worst type of bounce is one that comes from a user who is "hiding" behind an account that redistributes mail (a "redistribution list"), or a user whose Internet address has changed slightly but who is still subscribed to your list under his original address.

Redistribution lists typically (but not always) take some form of your list's name (such as "xxxxx-L-REDIST@foo.bar.com"), and thus their subscriptions tend to be easy to find. What is difficult is that you have no way of knowing which users (or how many users) are hidden behind this interface, nor any way of knowing what their userids are.

Forwarded accounts generally fall into one of two categories – those where the user has forwarded his own mail from one account to another rather than changing his subscription, and those where the user's system name has changed and the old address is still valid but is forwarding mail to the new address without the user being aware of it.

Let's say that suddenly you are bombarded with delivery errors for someuser@baz.net. Your immediate reaction is to set this person to NOMAIL or (in some cases) to delete him/her altogether. You therefore send set xxxxx-L nomail for someuser@baz.net to LISTSERV. LISTSERV responds: "No subscription for someuser@baz.net in list XXXXX-L."

In a best-case scenario, you can query the list for *@*.baz.net and find either a user like someuser@glork.baz.net (the address has changed and the local sysadmins didn't inform the user) or a redistribution-list account like xxxxx-L@baz.net. These are easily-fixed redistribution bounces. In the first case, you delete the user and let him or her resubscribe. In the second case, you can try sending a message to owner-xxxxx-l@baz.net with a cc: to postmaster@baz.net and inform them of the problem. If it persists, you could send a further message informing them that you are suspending the redistribution list's subscription until such time as they tell you the problem on their end is fixed, and simply set xxxxx-l@baz.net to NOMAIL.

The worst-case scenario is as follows: baz.net may be bouncing the mail to you, but there may not be a single subscription for baz.net in your list. Here's where you have to do some careful sleuthing. First, run a wildcard query such as QUERY xxxxx-l FOR *@*baz* or QUERY xxxxx-l FOR *baz*@*. The former will find users at baz.com, for instance, where baz.net is a synonym for baz.com. The latter query may seem somewhat strange, but it's possible that the mail is being routed through a gateway and the actual subscription is for xxxxx-l%baz.net@cunyvm.cuny.edu or similar.

Sometimes you will receive bounces from LISTSERV with a error header like this:

The enclosed message, found in the VISBAS-L mailbox and shown under the spool ID 19630445 in the system log, has been identified as a possible delivery error notice for the following reason: "Sender:", "From:" or "Reply-To:" field pointing to the list has been found in mail body.

Sometimes this is a legitimate bounce from a mail system that isn't compliant with Internet standards for mail, and the reason the "Sender:", "From:", and/or "Reply-To:" headers are significant is because if this mail were to be allowed through to the list it could very possibly start a loop with the non-compliant mail server. Normally this is a good thing; however, an unfortunate side-effect of the loop-checking code that catches this kind of bounce means that LISTSERV may treat replies to list mail from some mail clients as if they are delivery errors. LISTSERV has no way to know the difference between a bounce and a legitimate message that just happens to have unquoted included headers so it takes the conservative route and bounces it to the list owner as a "possible" delivery error. This way the list owner can (if he or she wants to) return the message to the user in question and ask them to either quote out or delete the headers from their replies.

In any case this is specifically known to be a problem with Pegasus Mail and some incarnations of the Microsoft Exchange Client, but there are probably other mail programs that do the same thing. The problem arises when the user's mail client includes the "Sender:", "From:", or "Reply-To:" fields that point back to the list itself (for instance, the above error was for VISBAS-L@PEACH.EASE.LSOFT.COM) in the quoted material and doesn't quote them correctly--that is to say, without a quoting character, or with a space between the quoting character and the included text. For instance, a reply from Pegasus with quoted material might include the following lines:

> Date: Tue, 31 Dec 1996 17:00:00 -0700
> Reply-to: Visual Basic List <VISBAS-L@PEACH.EASE.LSOFT.COM>
> From: Joe User <JOE@UNIX.FOO.COM>
> Subject: Re: 97 Style ToolBars
> To: VISBAS-L@PEACH.EASE.LSOFT.COM

The quoted lines below the user's reply would trigger LISTSERV's loop detection functions because there is a space between the ">" character and the "Reply-To:" and the "From:" headers.

The correct, netiquette-approved method of quoting these headers is to delete them entirely from the body of your message. Quoting is generally done for reasons of context and message headers are not needed for context. (Pegasus actually lets you toggle this on and off via the "Advanced options for replies" dialog. Other clients don't seem to have this function.) Note that Eudora quotes messages with no space between the ">" character and the quoted text, so this is not an issue with Eudora.

If necessary, subscribers using Pegasus can change the quoting character (at least they can in some versions of Pegasus; the author has not tested current versions) by editing their copy of PMAIL.INI and changing the value in

[General]
...
Commenting string = >

Normally this variable contains "> ", that is, ">" followed by a space character. If you remove the space, Pegasus quotes "properly" and this is no longer a problem. Other mail clients may or may not have similar configuration settings. As always, users should consult the documentation for their mail program before making changes to its configuration.

(Also, see Section 19.2 Loop-Checking Can Cause Occasional Problems with Quoted Replies).

LMail is an L-Soft mailer product for VM mainframes. When it receives error mail from remote hosts it translates the error into a standard format recognized by LISTSERV so that LISTSERV can take action as necessary. From time to time you may see such errors in your mailbox; they look like this:

-------------------------------------------------------------------------
Date: Fri, 8 Jan 2000 20:04:50 +0100
Reply-To: Postmaster@SEARN.SUNET.SE
From: RFC822 mailer (LMail release 1.2d/1.8d) <MAILER@SEARN.EXAMPLE.SE>
Subject: Undelivered mail
To: ERIC@SEARN.EXAMPLE.SE
cc: Postmaster@SEARN.SUNET.SE
X-Report-Type: Nondelivery; boundary="> Error description:"

An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes.

--> Error description:
Error-For: JACK@SEARN.SUNET.SE
Alias: JACK@SEARN.BITNET
Error-Code: 3
Error-Text: No such local user.

Error-For: JOE@SEARN.SUNET.SE
Alias: JOE@SEARN.BITNET
Error-Code: 3
Error-Text: No such local user.
Error-End: Two errors reported.

------------------------- Rejected message (5 lines) --------------------------
Date: Fri, 8 Jan 1993 20:04:47 +0100
From: Eric Thomas <ERIC@SEARN.BITNET>
To: JACK@SEARN.BITNET, JOE@SEARN.BITNET

The LMail codes stand for the following:

•	0 is used for all the weird errors that can't easily be classified, and LISTSERV takes no action on these codes by definition. This includes errors such as "invalid device name" or "device full" which have meaning only for the postmaster of the host that bounced the message.

The difference between 3 and 4 is that a 3 indicates there is no way to successfully send mail to the user, whereas 4 indicates the user cannot receive mail from the address your message came from. LMail uses code 4 when a local LMail user directs it to reject all mail coming from mailing lists, but to let private mail through. Typically you will not see very many 4 codes.

LISTSERV itself takes action on error codes 1, 3, and 4, and forwards anything else to the list owner.

LISTSERV supports several levels of automatic deletion based on error messages passed back to it in LMail format by certain remote systems. While auto-delete will not solve all of your bouncing mail problems, it has the potential to take care of most "permanent" errors (including "no such user" and "no such host"). However, note that auto-delete ignores "temporary" errors such as "host unreachable for 3 days", "system error", "disk quota exceeded", and so forth, such that users whose accounts generate "temporary" errors are not summarily deleted from the list.

By default, LISTSERV mailing lists generate a report which lets the list owner know what userids are causing problems, rather than deleting users at the first error LISTSERV understands. If the Delay() and Max() parameters are set to non-zero values for a list coded "Auto-Delete= Yes", LISTSERV will not take immediate action on mail delivery errors. You will receive an "auto-deletion monitoring report" daily to show you which subscribers are bouncing mail, what the error is, when it started, when the last error arrived, and how many errors have been received for the subscriber in total. By default, LISTSERV will wait 4 days (or for a maximum of 100 error messages per individual user) before deleting a subscriber.

If you code "Delay(0)", LISTSERV will not wait to take action, but will delete the subscriber at the first error LISTSERV understands. Note carefully that LISTSERV will not generate a daily error monitoring report when Delay(0) is used.

The default value is "Auto-Delete= Yes,Semi-Auto,Delay(4),Max(100)" for lists coded "Validate= No" and "Auto-Delete= No" for all other lists.

Under LISTSERV Lite, Auto-Delete= is available but deletes on the first bounce (e.g., "Delay(0),Max(1)") regardless of the Delay() and Max() settings.

Implementation of the "Auto-Delete=" keyword is discussed in detail in the List Keyword Reference document under "Error Handling Keywords."

Making a big increase to the DELAY threshold to provide more leniency during a holiday may not be a good idea. While it will indeed disable the monitor for the duration of the holiday, switching back to the normal threshold when you return will cause the monitor to delete all the users that had been bouncing during the holidays. In general, you should avoid making temporary changes to the DELAY threshold, because it takes the monitor a while to adapt to the new settings.

The best way to relax the rules during a long holiday is to leave the DELAY threshold unchanged but switch the monitor to passive mode ("Auto-Delete= Yes,Manual"). Nobody will be deleted over the holidays, but the monitor's cycle will not be perturbed. When you return, you should wait about a week before switching back to automatic mode. This is because, after a long holiday such as Christmas, it usually takes about 2 working days for system administrators to solve all problems. In some cases, the problems will have caused bounces to remain undelivered. So, by fixing the problems, the system administrators may actually send a flood of new bounces corresponding to problems that have now been solved. Unfortunately, since the monitor only receives NON-delivery reports, it has no way to know that these problems have in fact been solved. As a rule of thumb, you will note that your daily delivery error reports are much longer than usual over the vacation. When you return, you should wait until they are back to their normal size before switching back to automatic mode.

This functionality is not available in LISTSERV Lite.

There are two levels of automatic address probing available in LISTSERV.

This functionality is not available in LISTSERV Lite.

Active address probing is available for two reasons: first, to enhance subscription renewal functionality so that no "CONFIRM listname" response is required from subscribers in order to stay subscribed, and second, to enhance the ability of the auto-deletion feature to handle bounces that can't be parsed into something LISTSERV can recognize.

"Renewal= ...,Probe" activates this enhanced bounce processing feature, whereby subscribers are probed at subscription renewal time using the PROBE1 mail template. The "Probe" option makes subscription renewal passive rather than reactive; no "CONFIRM listname" response is needed from the user. In fact, the desired response from the user is to discard the message and do nothing, making the process very simple. LISTSERV also probes addresses that return mail delivery errors, and probe messages have a special signature in the return address that allows LISTSERV to uniquely identify any bouncing address, without having to understand the bounce itself.

If the probe bounces, LISTSERV first sends the PROBE2 template with a copy of the bounce, to show the user (if the account actually works in spite of the bounce) what garbage his mail system is sending people. LISTSERV then schedules a new probe for the next day, or deletes the user immediately, depending on the auto-delete policy. Every failure triggers a new daily probe until the user gets deleted or the problem gets fixed. The user can also save his subscription manually by sending a CONFIRM listname command (this is explained in PROBE2). This doesn't solve the underlying problem, so eventually the user should get tired of confirming in an emergency and notify his system administrators that the system is generating bounces saying (for instance) "Your message was registered at the MORONICUS mail gateway. Press F1 for more information" that cause the problem in the first place.

When used together with "Auto-Delete= ...,Full-Auto", the probe option deletes all delivery errors from bounced probes, even if LISTSERV can't understand the error. This means the list owner never ever has to see a single bounce from a probed address. The list, however, is kept clean because bad addresses are always detected. In fact, the biggest risk is that the users of the MORONICUS mail gateway will be deleted even though they do get their mail.

This being said, note carefully that all errors bounced by non-compliant mail hosts to the wrong address, and non-probe errors that are sent to the owner-listname address but are not in a format that LISTSERV can parse, will still show up in your error mailbox. If the bounce goes to the wrong address, LISTSERV never sees it and cannot probe it. If the error goes to the correct address (owner-listname) but isn't specific enough for LISTSERV to understand, while LISTSERV will be able to see it, it still won't be able to probe it. Finally, in some cases where the error is so vague (or constructed in a complicated manner that defies LISTSERV's attempts to parse it) the error may be passed to the LISTSERV postmaster, instead of to the list owner, for disposition, even if it was correctly returned to the owner-listname address.

Yet even with these restrictions, the author saw an error queue of 1300 errors/day shrink to under 50 errors/day by applying the ",Probe" parameter to seven high-volume lists, which in his opinion was much more acceptable.

This functionality is not available in LISTSERV Lite.

In effect, passive probing is very similar to active probing, but it is not tied to subscription renewal. Passive probing is enabled by default for small lists (e.g., <1K subscribers) but not for large ones due to the fact that passive probing does cost additional resources and large lists are often used for one-shot mailings where it is simply not effective to use those resources to probe addresses that will not be used a second time.

Passive probing operates by turning a certain percentage of your regular list messages into transparent probes that look like a normal message but also double as a probe, rather than sending out the explicit PROBE1 template as in active probing. You enable (or tune) passive probing by adding a ",Probe(xx)" parameter to the Auto-Delete= keyword setting. For instance,

where "30" is the number of days to wait between probes for any given user (the default is Probe(30). Subscribers with working mail systems will not see any difference, subscribers with flaky mail systems will occasionally receive a message showing that their mail bounced and saying that they should report the problem to their ISP, and of course plain bad addresses will go away.

In order to disable passive probing you set the probe parameter to 0, i.e.,

If you have users who for whatever reason should not be probed, then you can deactivate passive probing (and any other renewal you have set for the list) with the SET userid@host NORENEW command.

For lists coded "Subscription= Open", you can require confirmation on all new subscription requests, thus ensuring that LISTSERV has a clear mailing path back to the subscriber. In the past, a user could send a subscription for an open subscription list to LISTSERV, which upon acceptance would immediately start sending the user list mail. If the user was located behind a "broken" or one-way gateway, this produced immediate bounced mail until the list owner noticed and deleted the subscription. Note that requiring confirmation at the time of subscription does not guarantee that the clear mailing path will continue to exist permanently.

"Subscription= Open,Confirm" causes LISTSERV to send a Command Confirmation Request to the potential subscriber before actually adding the user to the list. The subscriber is requested to reply to the request by sending a validation "cookie" back to LISTSERV (this "cookie" being the hexidecimal number pulled from the subject line).

The Command Confirmation Request, while straightforward, has the potential to cause confusion if users do not read carefully the instructions that make up the request. LISTSERV expects confirmation codes to be sent in a specific way because some mail gateways add lines to the header of the message that LISTSERV doesn't understand. If a user forwards the request back to LISTSERV, or creates a new mail message to send the 'cookie' back, it usually will not work correctly. The sequence should thus be as follows:

You can code subscription renewal into your lists. This is one method to keep lists "pruned down" and avoid having large lists that are actually distributing mail to only a fraction of the users. For instance, you may have a number of subscriptions set to NOMAIL for one reason or another. NOMAIL user(a) may have forgotten that he has a subscription; user(b) may have set NOMAIL instead of unsubscribing; user(c) may no longer exist because she graduated or no longer works for the service provider; you may have set user(d) to NOMAIL because of recurrent mail delivery errors. Requiring a periodic confirmation of subscriptions is therefore a reasonable course of action for large, non-private lists.

Subscription renewal is disabled by default. If you do not want subscription renewal, or if you wish to turn it off, simply do not include a "Renewal=" keyword in your list header.

To add subscription renewal, you add the following keyword to the header of your list:

where interval is a period of time such as Weekly, Yearly, 6-monthly, or something similar, and Delay(number) is an integer corresponding to how many days LISTSERV will wait for the renewal confirmation to arrive. (See "Renewal=" in the List Keyword Reference document for more information on renewal and delay periods; see Section 4.9 Address Probing for more information on the "Probe" parameter. You can have multiple interval parameters; again, see the entry for "Renewal=" in the List Keyword Reference document for details).

The confirmation request mailing asks the subscriber to send the command CONFIRM listname back to LISTSERV. If the subscriber does not do so within a certain length of time, LISTSERV automatically deletes the subscription. The default delay time is 7 days. If you wish to use the default delay time, it is not necessary to code ",Delay(7)" into your Renewal parameters.

Note: You may wish to increase the delay time to accommodate users whose subscriptions expire over holidays (such as the Christmas/New Year's week) in order to avoid accidental deletions. Also, be aware that confused subscribers can and will send the CONFIRM command back to the list, rather than to LISTSERV. LISTSERV's default filter will catch these commands and forward them to the userid(s) defined by the "Errors-To=" keyword.

It is possible to waive subscription renewal for certain users (such as list owners, editors, redistribution lists, etc.). In order to do this, simply issue the command

[QUIET] SET listname NORENEW FOR net-address

to LISTSERV. It is most advisable to do this in the case of redistribution lists, as they broadcast the renewal notice to their users, who a) cannot renew the subscription and b) become very confused when they see the notice, often sending "what does this mean?" mail to the list.

You can also issue the CONFIRM command for a subscriber:

[QUIET] CONFIRM listname FOR net-address

Note: "Active" users of the list (that is, people who post regularly to the list) will never be required to renew their subscriptions, nor (if subscription "probing" is enabled) will they ever be sent the passive subscription probe. LISTSERV presumes that such users have valid addresses and does not require a renewal confirmation from them.

If a user sends more than 50 consecutive invalid commands to LISTSERV, LISTSERV automatically serves that user off so that further commands from that user will be ignored. Should a user become served off in this fashion, it is possible for the list owner or any other user to issue a SERVE net-address command to restore that user's access. As with all other LISTSERV commands, the SERVE command is sent to LISTSERV.

While served off, the user will be unable to set personal options and will be unable to subscribe or unsubscribe to lists on that server. Note that a user will likely be served off of one particular LISTSERV site but not others, and also that the user may not even realize that he has been served off (in spite of the fact that LISTSERV sends notification to the user to that effect).